Cisco Router OSPF Design and Implementation Guide William Parkhurst, PhD, CCIE $54.95 0-07-048626-3 |
![]() ![]() |
Chapter: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 |
Reserve your copy at a Beta Bookstore near you! |
Contact Bet@books © 1998 The McGraw-Hill Companies, Inc. All rights reserved. Any use of this Beta Book is subject to the rules stated in the Terms of Use. |
In the previous chapter, almost all of the OSPF configuration commands were covered in sufficient detail. These commands were presented on relatively simple network configurations. The network configurations were kept simple so as not to obscure the task that was at hand, to learn the operation of OSPF. In this chapter we will examine OSPF configurations for more complex networks, networks that include frame relay and ISDN. The OSPF commands that were skipped in chapter 11 will be presented in this chapter and we will present those commands that enable efficient OSPF implementations over frame relay and demand circuits such as ISDN.
Frame Relay – An Overview
Frame relay is a wide area network protocol that operates at layer two of the OSI model. Being a layer two protocol means that frame relay is not routable, but is a switched protocol like ethernet. A basic frame relay network is shown in figure 12.1.
The components of a frame relay network include one or more frame switches that are used to transport the frame relay packet through the WAN. A frame connection consists of a data terminal equipment (DTE) interface that is usually part of the equipment on a customer’s premise. The data circuit-terminating equipment (DCE) interface supplies the clock for the synchronous serial connection as is usually provided by the WAN service
provider. User data from the upper layers is encapsulated in a frame relay packet and then switched through the WAN to the exit point from the cloud. The frames are switched through the network based on a data link connection identifier (DLCI). The DLCI is the frame relay address and can be two to four bytes in length as shown in figure 12.2. The WAN service provider normally assigns DLCIs.
Flags 0111 1110 |
Address 2-4 bytes |
Data Variable length |
FCS 2 bytes |
Flags 0111 1110 |
Figure 12.2. Frame relay frame format.
The one byte flags field at the beginning and end of the frame is used to signal the start and end of the frame. A DLCI can be 10, 17, or 24 bits in length. The length of the DLCI is determined by examining the EA bits in the address field as shown in figure 12.3. The 2-byte frame relay address filed is the default and can be increased to 3 or 4 byes in length through the use of the address extension (EA) bits. If EA is equal to 1 then this indicated the last byte of the DLCI. Three bits are used for congestion control. The forward-explicit congestion notification (FECN) bit is set to 1 to notify a DTE device that there is congestion in the frame transmission path from source to destination. The backward-explicit congestion notification (BECN) bit is set to 1 to indicate congestion in the opposite direction, from destination to source. Routers use the discard eligibility (DE) bit when congestion occurs. When the DE bit is 1, this signals the frame switch that
7 6 5 4 3 2 1 0
DLCI MSB |
C/R |
EA=0 |
||
DLCI LSB |
FECN |
BECN |
DE |
EA=1 |
7 6 5 4 3 2 1 0
DLCI MSB |
C/R |
EA=0 |
||
DLCI |
FECN |
BECN |
DE |
EA=0 |
DLCI LSB |
D/C |
EA=1 |
7 6 5 4 3 2 1 0
DLCI MSB |
C/R |
EA=0 |
||
DLCI |
FECN |
BECN |
DE |
EA=0 |
DLCI |
EA=0 |
|||
DLCI LSB |
D/C |
EA=1 |
c. 4-byte frame relay address field.
Figure 12.3. Frame relay address fields.
this frame should be discarded first if congestion occurs. The C/R bit is currently not used. The format of a frame relay frame is extremely simple compared to other protocols. There is only one format and no control fields so error and flow control cannot be accomplished. Frame relay depends on the reliability of modern digital communication links and assumes that upper layer protocols will handle the task of detecting re-sending lost frames. This simple frame format makes frame relay a very fast and efficient protocol.
The DLCI is used between the DTE and DCE to multiplex frames from different sources and the DLCI has local significance only. This means that DLCIs do not have to be globally unique. All four routers in figure 12.1 can use the same DLCI without confusion since they only have meaning between the local DTE and DCE devices.
The status of the link between the DTE and DCE devices and the status of connections in the frame relay WAN is provided by the local management interface (LMI) protocol. The LMI interface also performs an inverse ARP function that is used to dynamically inform the DTE of the DLCI that has been assigned to the interface.
Frame Relay Topologies
Frame relay connections can be configured using three different topologies. The first topology is to use a fully meshed point-to-point frame relay architecture as shown in figure 12.4.
In figure 12.4 we have three routers that are fully meshed, meaning that each router has a connection to every other router. Each connection is a permanent virtual connection (PVC) that has been established by the WAN service provider. PVCs differ from switched virtual circuits (SVC) which require a call setup process to establish the link and a call terminate process to remove the link. PVCs are always established, eliminating the need for call setup and termination processing. Each router in figure 12.4 has two frame relay PVCs, one to each of the other routers, but each router is using only one serial interface. Multiple frame relay PVCs can be configured using sub-interfaces on the physical serial interface. A sub-interface is a logically separate interface that shares the same physical interface with possible other logical sub-interfaces. We have seen that every router interface, whether it is ethernet, token ring, or a serial interface, must be configured on a separate logical IP subnet. Therefore, the network of figure 12.4 requires three separate IP subnets in order to configure a fully meshed topology. The topology is referred to as point-to-point since every link behaves like a standard synchronous serial link. Fully meshed frame relay topologies are easy to configure but can be quite expensive. We would have to purchase three PVCs from our service provider in order to achieve a full mesh for the network in figure 12.4.
One method of reducing the number of PVCs that are required but still maintaining connectivity between all networks is to use a partially meshed point-to-point frame relay topology (figure 12.5). This arrangement is also referred to as a hub and spoke topology with one of the routers being the hub and the other routers are the spokes. In figure 12.5 we only need two PVCs and two logical IP subnets in order to achieve full connectivity between the networks.
The spoke routers only have one frame relay PVC, the connection to the hub router. For this topology a spoke router can use either a standard serial interface (router r2) or a sub-interface (r3). The hub router must use sub-interfaces on the serial interface since it is attaching to two separate logical IP subnets. The number of subnets for this configuration has been reduced from 3 to 2. The number of required frame relay PVCs has also been reduced from 3 to 2. This not only saves us money on PVCs but also reduces that number of valuable IP subnets that must be used.
The third and final frame relay topology is called a multi-point configuration as shown in figure 12.6.
Figure 12.6. Multi-point frame relay topology.
The network in figure 2.6 seems identical to the network in figure 2.5. Physically they are the same but notice that we only need one logical IP subnet for the multi-point configuration. Since we are using only one IP subnet none of the serial interfaces need to use sub-interfaces but we will see that to configure this topology we will need to use one sub-interface on each of the router. Table 12.1 lists the PVC and logical IP subnet requirements for the various topologies for two to ten routers. Review the three topology diagrams and make sure you understand the difference between them. An understanding of the three frame relay topologies is critical for the proper configuration of Cisco routers using OSPF over a frame relay WAN.
Table 12.1. PVC and IP subnet requirements for each frame relay topology.
Number of Routers |
Fully Meshed Point-to-point |
Partially Meshed Point-to-point |
Multipoint |
|||
PVCs |
IP Subnets |
PVCs |
IP Subnets |
PVCs |
IP Subnets |
|
2 |
1 |
1 |
1 |
1 |
1 |
1 |
3 |
3 |
3 |
2 |
2 |
2 |
1 |
4 |
6 |
6 |
3 |
3 |
3 |
1 |
5 |
10 |
10 |
4 |
4 |
4 |
1 |
6 |
15 |
15 |
5 |
5 |
5 |
1 |
7 |
21 |
21 |
6 |
6 |
6 |
1 |
8 |
28 |
28 |
7 |
7 |
7 |
1 |
9 |
36 |
36 |
8 |
8 |
8 |
1 |
10 |
45 |
45 |
9 |
9 |
9 |
1 |
Configuring Frame Relay
Before we configure frame relay on a Cisco router list the parameters of a normal serial interface.
r1#show interfaces serial 0
Serial0 is up, line protocol is up
Hardware is HD64570
Internet address is 172.16.5.2/24
MTU 1500 bytes, BW 38 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
r4#show ip interface serial 0
Serial0 is up, line protocol is down
Internet address is 172.16.5.2/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is enabled
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Security level is default
Split horizon is enabled
Notice and remember that the encapsulation is HDLC and that split horizon is enable.
To configure a serial interface for frame relay we need to change the encapsulation and set the LMI type.
r1(config)#interface serial 0
r1(config-if)#encapsulation ?
atm-dxi ATM-DXI encapsulation
bstun Block Serial tunneling (BSTUN)
frame-relay Frame Relay networks
hdlc Serial HDLC synchronous
lapb LAPB (X.25 Level 2)
ppp Point-to-Point protocol
sdlc SDLC
sdlc-primary SDLC (primary)
sdlc-secondary SDLC (secondary)
smds Switched Megabit Data Service (SMDS)
stun Serial tunneling (STUN)
x25 X.25
r4(config-if)#encapsulation frame-relay
r4(config-if)#frame-relay lmi-type ?
cisco
ansi
q933a
r4(config-if)#frame-relay lmi-type ansi
The lmi-type parameter specifies the flavor of the lmi protocol. To ensure interoperability with non-Cisco equipment use lmi-type ansi. At this point re-list the parameters of the serial interface.
r4#show interfaces serial 0
Serial0 is up, line protocol is down
Hardware is HD64570
Internet address is 172.16.5.2/24
MTU 1500 bytes, BW 38 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec)
r4#show ip interface serial 0
Serial0 is up, line protocol is up
Internet address is 172.16.5.2/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is enabled
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Security level is default
Split horizon is disabled
The change in the encapsulation to frame relay should not surprise us but the fact that split horizon is disabled is interesting and can be a source of great pain if you forget this fact. In chapter 13, Route Redistribution, we will see the ramifications of having split horizon disabled when redistributing protocols. For now, remember that changing the encapsulation on a serial interface disables split horizon. Now we will configure a sub-interface for serial interface 0.
r1(config)#interface serial 0
r1(config-if)#no ip address
r1(config-if)#exit
r1(config)#interface serial 0.1 ?
multipoint Treat as a multipoint link
point-to-point Treat as a point-to-point link
r4(config)#interface serial 0.1 point-to-point
r4(config-subif)#ip address 172.16.5.2 255.255.255.0
r4(config-subif)#frame-relay interface-dlci 103 ?
interface Serial0
no ip address
encapsulation frame-relay
frame-relay lmi-type ansi
interface Serial0.1 point-to-point
ip address 172.16.5.2 255.255.255.0
frame-relay interface-dlci 103
When using sub-interfaces the IP address is given to the sub-interface and not the major serial interface, that is why the command no ip address is used for serial interface 0. Encapsulation is set at the major interface level and will be used for all sub-interfaces that are created. Under sub-interface 0.1 we need to specify whether this is a point-to-point or multipoint interface. The difference will be explored when you examine OSPF configuration issues with frame-relay. When sub-interfaces are created, the DLCI assigned to the sub-interface has to be specified. LMI can talk to the frame switch and determine what DLCIs have been assigned, but since we are using sub-interfaces the router has no way of knowing which DLCI goes with which interface so they need to be specified. At this point re-list the interface parameters.
Serial0 is up, line protocol is down
Internet protocol processing disabled
r4#show ip interface serial 0.1
Serial0.1 is up, line protocol is up
Internet address is 172.16.5.2/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is enabled
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Security level is default
Split horizon is enabled
IP processing has been disabled on the major interface, serial 0, and has been transferred to the sub-interface. The most important item is split horizon on the sub-interface, which we can see is now enabled. Again, this is extremely important to remember so commit the following to memory.
We have partially seen how to configure frame relay on a serial interface but only to reveal the state of split horizon for various configurations. Before examining frame relay configuration in depth we will look at configuring a Cisco router as a frame switch so we can configure our own frame cloud for experimentation.
Configuration a Frame Relay Switch – Point-to-Point Fully Meshed Topology
The first configuration we need to examine is for the network of figure 12.4, a fully meshed point-to-point frame relay network. The router that we use as the frame switch will need three serial interfaces. We will the frame switch as shown in figure 12.7.
Figure 12.7. Using a Cisco router as a frame relay switch.
The configuration for the frame relay switch needed to implement the network of figure 7.4 is shown below.
hostname frame_switch
frame-relay switching
interface Serial0
no ip address
encapsulation frame-relay
no fair-queue
clockrate 2000000
frame-relay lmi-type ansi
frame-relay intf-type dce
frame-relay route 102 interface Serial1 201
frame-relay route 103 interface Serial2 301
interface Serial1
no ip address
encapsulation frame-relay
clockrate 2000000
frame-relay lmi-type ansi
frame-relay intf-type dce
frame-relay route 201 interface Serial2 102
frame-relay route 203 interface Serial0 302
interface Serial2
no ip address
encapsulation frame-relay
clockrate 2000000
frame-relay lmi-type ansi
frame-relay intf-type dce
frame-relay route 301 interface Serial1 103
frame-relay route 302 interface Serial0 203
The first command is used to enable frame switching on the router. Each serial interface is going to switch input frames to one of two routers. Serial 0 is the DCE for router r1, serial 1 is the DCE for router r2, and serial 2 is the DCE for router 3 in figure 12.4. When a frame is sent to the frame switch, the frame is switched based on the DLCI number. When serial interface 0 receives a frame from router r1, the frame will be addressed with DLCI 102 or 103 (the DLCIs were picked so the first digit represents the originating router, the second digit is 0 and the third digit is the destination router). So DLCI 102 is from router r1 to router r2. We could have used the same pairs of DLCIs on each router since DLCIs have only local significance but this tends to be confusing. Normally the service provider sets the DLCIs, but since we are picking them, we will try to make them clear. Each interface has common configuration commands as listed below.
The frame-relay route command instructs the frame switch that any frame received with a DLCI indicated in the input DLCI field should be routed (or switched) to the appropriate interface with the DLCI being replaced with the output DLCI. For example, when router r1 sends a frame to router r2 the DLCI used is 102. When serial interface 0 receives this frame, the input DLCI number is checked. If the input DLCI equals 102, the DLCI number is replaced by 201 and switched to interface serial 1 and sent to router r2.
DTE Router Configuration
The configuration for a point-to-point fully meshed frame relay topology is listed below for router r1.
hostname r1
interface Serial0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay lmi-type ansi
interface Serial0.2 point-to-point
ip address 172.16.1.1 255.255.255.0
frame-relay interface-dlci 102
interface Serial0.3 point-to-point
ip address 172.16.2.1 255.255.255.0
frame-relay interface-dlci 103
Since we have two frame relay PVCs for each router we must use sub-interfaces since for this topology each PVC is an a separate logical IP subnet. For the major serial interface 0 we disable IP routing by using the command no ip address. The encapsulation is set to frame relay and the LMI type is set to ansi to match the LMI type of the frame switch. The sub-interfaces are of type point-to-point, which matches the frame relay topology that we are trying to configure. The frame-relay interface-dlci command must be used since we are using sub-interfaces and we need to inform the router which DLCI goes with which sub-interface. Router r1 is using IP subnets 172.16.1.0 and 172.16.2.0. The sub-interface numbers were chosen for convenience. Sub-interface 0.2 is the connection to r2 router r2 and sub-interface 0.3 is the connection to router r3. The configurations for routers r2 and r3 are shown below.
hostname r2
interface Serial0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay lmi-type ansi
interface Serial0.1 point-to-point
ip address 172.16.1.2 255.255.255.0
frame-relay interface-dlci 201
interface Serial0.3 point-to-point
ip address 172.16.3.2 255.255.255.0
frame-relay interface-dlci 203
hostname r3
interface Serial0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay lmi-type ansi
interface Serial0.1 point-to-point
ip address 172.16.2.3 255.255.255.0
frame-relay interface-dlci 301
interface Serial0.3 point-to-point
ip address 172.16.3.3 255.255.255.0
frame-relay interface-dlci 302
We are now ready to configure OSPF over the frame relay network. Since we are using a fully meshed point-to-point frame relay network, everything that we earned about OSPF in Chapter 11 still applies. The links between routers look like normal serial interfaces so no new OSPF commands or configurations are necessary. No designated router or backup designated router will be elected for the network since this only occurs on broadcast networks. The next two topologies won’t be so easy.
Configuration a Frame Relay Switch – Point-to-Point Partially Meshed Topology
The configuration of the frame switch for the partially meshed point-to-point topology of figure 7.5 is listed below.
hostname frame_switch
frame-relay switching
interface Serial0
no ip address
encapsulation frame-relay
no fair-queue
clockrate 2000000
frame-relay lmi-type ansi
frame-relay intf-type dce
frame-relay route 102 interface Serial1 201
frame-relay route 103 interface Serial2 301
interface Serial1
no ip address
encapsulation frame-relay
clockrate 2000000
frame-relay lmi-type ansi
frame-relay intf-type dce
frame-relay route 201 interface Serial0 102
interface Serial2
no ip address
encapsulation frame-relay
clockrate 2000000
frame-relay lmi-type ansi
frame-relay intf-type dce
frame-relay route 301 interface Serial0 103
Can you detect the differences in this configuration from the fully meshed configuration? The configuration for interface serial 0 did not change since router r1 is now the hub router and still has two PVCs. Routers r2 and r3 now only have 1 PVC so we only need one frame-relay route command for serial interfaces 1 and 2. If router r2 wants to send a packet to router r3, how does it get there? Sounds like we need a routing protocol. We will see how to handle this problem shortly. First, we need to reconfigure routers r1, r2 and r3. Router r1 does not need to be reconfigured from the previous example. Since routers r2 and r3 have only one PVC we can either use one sub-interface or no sub-interfaces, so we will do one of each so see how this is done. The configuration for router r2 is listed below.
hostname r2
interface Serial0
ip address 172.16.1.2 255.255.255.0
encapsulation frame-relay
no fair-queue
frame-relay lmi-type ansi
Router r2 is not using a sub-interface so LMI can determine the DLCI number by communicating with the frame switch. This is why we did not need to specify the DLCI. The configuration for router r3 will be a bit different.
hostname r3
interface Serial0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay lmi-type ansi
interface Serial0.1 point-to-point
ip address 172.16.2.3 255.255.255.0
frame-relay interface-dlci 301
Since a sub-interface is being used on router r3 the frame-relay interface command is necessary in order to associate the DLCI with the proper interface.
OSPF – Frame Relay Partially Meshed Point-to-Point Topology.
The partially meshed point-to-point topology is going to cause OSPF some problems. This is not a broadcast topology like ethernet or a true point-to-point topology as we have seen with normal serial interfaces. From routers r2 and r3, the network does look like a normal serial link, but from router r1’s perspective the network is neither. We need to fool OSPF on router r1 that the network is a broadcast network by using an OSPF interface command that we skipped in Chapter 11.
hostname r1
interface Serial0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay lmi-type ansi
interface Serial0.2 point-to-point
ip address 172.16.1.1 255.255.255.0
ip ospf network broadcast
frame-relay interface-dlci 102
interface Serial0.3 point-to-point
ip address 172.16.2.1 255.255.255.0
frame-relay interface-dlci 103
ip ospf network broadcast
The interface command ip ospf network broadcast will fool OSPF into believing that this is a broadcast network and not a NBMA network. Routers r1, r2, and r3 will form relationships as if they were on an ethernet network, a designated and backup designated router will be elected. The command ip ospf network broadcast will also need to be configured on routers r2 and r3.
hostname r2
interface Serial0
ip address 172.16.1.2 255.255.255.0
ip ospf network broadcast
encapsulation frame-relay
no fair-queue
frame-relay lmi-type ansi
hostname r3
interface Serial0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay lmi-type ansi
interface Serial0.1 point-to-point
ip address 172.16.2.3 255.255.255.0
ip ospf network broadcast
frame-relay interface-dlci 301
The ip ospf network broadcast command is all we need to use to enable the proper operation of OSPF over the partially meshed point-to-point network. You can now configure OSPF as you have learned from chapter 11 and everything will work just fine, except for one thing. Which router should be the designated router? On a true broadcast network such as ethernet, every router could directly communicate with every other router. This is not the case for this topology. Only router r1 has a direct communication link with the other routers, so router r1 needs to be elected DR. From what you learned in Chapter 11, can you think of three ways to influence the DR election? The first way is by the proper configuration of loopback addresses. If loopbacks are used, then they are used as the routers OSPF ID and the router with the highest ID is elected DR. So we can configure loopbacks on router r1, r2 and r3 and make sure that router r1’s loopback address is higher than routers r2 and r3. We could configure the OSPF priority of router r1’s serial sub-interfaces to be greater than one, which will force r1 to be elected DR. Finally, we can set the OSPF priority of the serial interfaces on routers r1 and r2 to be zero, making them ineligible to be elected DR.
OSPF – Frame Relay Partially Meshed Point-to-Multipoint Topology.
The multi-point partially meshed configuration of figure 12.6 differs from the partially meshed point-to-point configuration of figure 12.5 only in the assignment of subnets. The PVCs are assigned the same subnet making this a point-to-multipoint configuration. The configuration of the frame switch will not change from the previous scenario. The configurations for routers r1, r2, and r3 are given below.
hostname r1
interface Serial0
no ip address
encapsulation frame-relay
bandwidth 38
no fair-queue
frame-relay lmi-type ansi
interface Serial0.1 multipoint
ip address 172.16.1.1 255.255.255.0
ip ospf network point-to-multipoint
frame-relay interface-dlci 102
frame-relay interface-dlci 103
Router r1 now only needs one sub-interface since both PVCs are on the same subnet. The sub-interface is declared as a multipoint interface and both DLCIs are applied to the sub-interface. The OSPF network type has been changed from broadcast to point-to-multipoint. This will force OSPF to treat the frame relay network as a multi-access broadcast network and a DR and BDR will be elected. As in the previous example make sure that the hub router, r1, is elected DR.
hostname r2
interface Serial0
ip address 172.16.1.2 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint
bandwidth 38
no fair-queue
frame-relay lmi-type ansi
hostname r3
interface Serial0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay lmi-type ansi
interface Serial0.1 multipoint
ip address 172.16.1.3 255.255.255.0
ip ospf network point-to-multipoint
frame-relay interface-dlci 201
Split horizon will be enabled on the serial interface for routers r1 and r3 but will be disabled for router r2 since a sub-interface is not being used. Also notice that on router r2 the DLCI was not specified because it will be learned through LMI.
OSPF and Demand Circuits
A demand circuit is a link that is only activated when traffic that has been designated as interesting needs to be sent across the link. Demand circuits are usually provided by a service provider and the user is only charged for the time the circuit is in use. Running a routing protocol over a demand circuit can be quite expensive since IP routing protocols periodically send some type of traffic. RIP sends the routing table every 30 seconds and OSPF sends hello packets every 10 seconds. Normally OSPF would not be run across a demand circuit because the periodic traffic would tend to keep the link up. One solution is to not run any routing protocol across the link and use static routes on either end of the demand circuit. A new interface command has been added to the OSPF bag of tricks for demand circuits.
interface bri0
ip ospf demand-circuit
This command will suppress OSPF hellos and periodic refreshes of LSAs from being transmitted across the link after the initial exchange of OSPF link-state information. This command only needs to be used on one side of the demand circuit for point-to-point connections and on the hub for a multipoint connection. Below is a sample ISDN configuration using the demand circuit command.
hostname r2
username R3 password 0 cisco
isdn switch-type basic-ni1
interface Loopback0
ip address 172.16.200.1 255.255.255.0
interface BRI0
ip address 130.10.10.2 255.255.255.0
encapsulation ppp
ip ospf demand-circuit
bandwidth 56
isdn spid1 31622081880101 2208188
isdn spid2 31622081890101 2208189
dialer idle-timeout 60
dialer map ip 130.10.10.3 name r3 speed 56 broadcast 2208190
dialer map ip 130.10.10.3 name r3 speed 56 broadcast 2208191
dialer load-threshold 100 outbound
dialer-group 1
ppp authentication chap
If you have configured a virtual-link across the ISDN circuit, the virtual-link will keep the ISDN circuit up even if you are using ip ospf demand-circuit in your configuration.
![]() ![]() Chapter: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 |
Reserve your copy at a Beta Bookstore near you! |
Contact Bet@books © 1998 The McGraw-Hill Companies, Inc. All rights reserved. Any use of this Beta Book is subject to the rules stated in the Terms of Use. |